Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-115.txt

Text File | 1994-12-08 | 43.3 KB | 1,100 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 16 Jun 92       Volume 1 : Issue 115

Today's Topics:

    More user input to applications
    Lasguage Systems Fortran & Quadra
    Menu
    how good is MacApp?
    Off-screen Port Help & Interface Guidelines Question...
    3d graphics programming
    Trouble with resumeCmd (Sound Manager)
    preloaded and purgable resources (Q)
    'STR ' resource question
    How to swab two bytes?


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Hugh Fisher)
Subject: More user input to applications
Organization: Research School of Chemistry, ANU
Date: Sun, 10 May 92 23:43:39 GMT

  About a month ago I brought my Macintosh, complete
  with Talking Moose, into the office to do some work
  (and to try and make some converts from IBM PCs).
  The moose made quite an impression on passer-bys
  while I was elsewhere, until someone nervously
  asked me "That thing doesn't know when somebody
  walks past, does it?" I reassured them it was just
  coincidence, but now I'm wondering whether the
  computer should know when you're around?

  An example in "TOG on Interface" is that of choosing
  to print a 75 page document, then going home without
  remembering to click OK on the dialog. Tog suggested
  a time out, but if the computer had an eye tracker,
  small CCD camera, or even a pressure sensitive seat
  cushion it could shout "Hey, come back!" instead.

  So, should our Macintoshes get cameras, datagloves,
  eye trackers, ... neural interfaces? As a techie
  I like that sort of thing, but would the general
  reaction be more like that to my moose instead?

    Hugh Fisher
    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Rick Holzgrafe)
Date: 14 May 92 22:51:59 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(Hugh Fisher) writes:
>   An example in "TOG on Interface" is that of choosing
>   to print a 75 page document, then going home without
>   remembering to click OK on the dialog. Tog suggested
>   a time out, but if the computer had an eye tracker,
>   small CCD camera, or even a pressure sensitive seat
>   cushion it could shout "Hey, come back!" instead.

Turn it around: I want a computer that doesn't need all
that hardware because I've always got it with me. In my
dreams, I own a computer that unfolds like a newspaper
(not one of these tiny-screened, massive PowerBooks :-)
and which I can simply keep tucked in a pocket. It
networks automatically via infrared (or something) and
is run by my finger or a pen, no keyboard. If I forget
to click "OK", I can remember at any later time and it'll
print on the next available printer. And since it's
always with me, it can just cough discreetly if it thinks
I've forgotten to do something important, like clicking
that button.

Yeah, I know. "In my dreams."

>     Hugh Fisher
>     [e-mail]

- -- Rick Holzgrafe, a member of the Taligentsia
   [e-mail]
   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ephraim Vishniac)
Date: 15 May 92 13:57:31 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA

In article <[e-mail]> [e-mail] (Rick Holzgrafe) writes:
>Turn it around: I want a computer that doesn't need all
>that hardware because I've always got it with me. In my
>dreams, I own a computer that unfolds like a newspaper
>(not one of these tiny-screened, massive PowerBooks :-)
>and which I can simply keep tucked in a pocket. It
>networks automatically via infrared (or something) and
>is run by my finger or a pen, no keyboard. If I forget
>to click "OK", I can remember at any later time and it'll
>print on the next available printer. And since it's
>always with me, it can just cough discreetly if it thinks
>I've forgotten to do something important, like clicking
>that button.

>Yeah, I know. "In my dreams."

Some dreams are coming true.

Back when the only kinds of Mac were "skinny" and "fat," someone
posted an article to net.micro.mac describing a dream he'd had. In his
dream, he was working with his full-color Mac (this was late '84,
probably) early in the morning when the Mac told him it was time for
breakfast. But it didn't pop up an alert, or say "It's time for
breakfast." or anything so mundane.  It showed him a sort of
advertisement for breakfast, with a moving aerial view of sunrise over
rolling green hills.

Now we've got color, the Notification Manager, AppleEvents, and
Quicktime. Anybody want to take a stab at prototyping the Breakfast
Alert Dream?

- --
Ephraim Vishniac    [e-mail]   [e-mail]
 Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142
        One of the flaws in the anarchic bopper society was
        the ease with which such crazed rumors could spread.

---------------------------

From: [e-mail] (Jari Multisilta)
Subject: Lasguage Systems Fortran & Quadra
Date: 15 May 92 11:24:41 GMT
Organization: University of Tampere, Finland

Hello

Does anybody know how to compile fortran code for Mac Quadra by
using Language Systems Fortran 2.1?

Our old fortran applications won't run because they require 68020 and
68881 processors (the Quoadra don't have one).

I have tried to link  with NoChipCheck.o library but it generates
mysteroius errors (out of memory!) in for example in fx.

Thanks,

       Jari Multisilta, researcher
       Tampere univ. of tech., dept. of math.

+++++++++++++++++++++++++++

From: [e-mail]
Date: 15 May 92 14:21:29 GMT
Organization: Bell-Northern Research

In article <[e-mail]>, [e-mail] (Jari Multisilta) writes:
|> Hello
|>
|> Does anybody know how to compile fortran code for Mac Quadra by
|> using Language Systems Fortran 2.1?
|>
|> Our old fortran applications won't run because they require 68020 and
|> 68881 processors (the Quoadra don't have one).
|>
|> I have tried to link  with NoChipCheck.o library but it generates
|> mysteroius errors (out of memory!) in for example in fx.
|>
|> Thanks,
|>
|>        Jari Multisilta, researcher
|>        Tampere univ. of tech., dept. of math.

You probably need to upgrade to LS FORTRAN 3.0, which handles 68040
machines.

- ---------------------------------------------------------------------------
Matt Holiday                                      #include <std/disclaimer>
[e-mail]
BNR Richardson

---------------------------

From: [e-mail] (Stephen Jones)
Subject: Menu
Date: 15 May 92 14:20:28 GMT
Organization: University of Tennessee, Knoxville

Has anyone had any experience with placing multiple identical
hierarchical menus dynamically into a menu ?  The problem I am having is
finding out which menu has been selected ( since I create them all from
the same resource and their resource ID is returned upon selection ).

  As I see it my options are :
1. Limit the number of H. menus available by making a seperate identical
resource ( different ID #s )for each one ( I'm trying this but my code
will not work, it displays the menu name but not the H. menu ) ???

2. Copy the old resource, get a unique ID, and insert the resource. (
This just seems like to much of a hassle )

    Thanks for any help/opinions anyone has to offer.

                Stephen Jones

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: Fri, 15 May 1992 15:07:58 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Stephen Jones) writes:
>Has anyone had any experience with placing multiple identical
>hierarchical menus dynamically into a menu ?  The problem I am having is
>finding out which menu has been selected ( since I create them all from
>the same resource and their resource ID is returned upon selection ).

You've run into one of the gotchas of menus.  (and there are so many)
Unlike, for example, WIND and CNTL resources, a MENU resource is not a
simple template.  Rather, it is the actual menu data structure itself.  The
object that gets inserted into the system menu list is the actual resource
handle, not a copy.

>  As I see it my options are :
>1. Limit the number of H. menus available by making a seperate identical
>resource ( different ID #s )for each one ( I'm trying this but my code
>will not work, it displays the menu name but not the H. menu ) ???

You must make sure that the "parent" item contains the correct menu ID for
its sub-menu.  You can change this on the fly use _SetItemMark.  Note that
you must type-cast the menu ID to CHAR in order to make _SetItemMark happy.

>2. Copy the old resource, get a unique ID, and insert the resource. (
>This just seems like too much of a hassle )

There's no real alternative, unfortunately.  You could clone the resource
handle and then try to manually duplicate what _GetMenu/_NewMenu do to
initalize the data-structure, but Compatability Hell awaits those who
attempt such things.  :-)   Of course, all of this would be very easy if
there were an _InitializeMenuHandle function.  Oh well.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 15 May 1992 18:10:33 GMT

[e-mail] (Stephen Jones) writes:
>Has anyone had any experience with placing multiple identical
>hierarchical menus dynamically into a menu ?  The problem I am having is
>finding out which menu has been selected ( since I create them all from
>the same resource and their resource ID is returned upon selection ).

There _menu_ id is returned on selection.  There's a big difference between
a menu id and a resource id.  You're right that you can't tell which
one was selected (sigh).

Here's what Eudora does, minus a few oddities and error checking:

  savedMHandle = NewMenu(NEW_TO_HIER_MENU,"");
  for (menu=NEW_TO_HIER_MENU;menu<=INSERT_TO_HIER_MENU;menu++)
  {
    mHandle = savedMHandle;
    if (menu>NEW_TO_HIER_MENU) HandToHand(&mHandle);
    (*mHandle)->menuID=menu;
    InsertMenu(mHandle,-1);
  }

Note that it does NOT create a resource for every menu; it just dups the
handle and stuffs in a new menu id.  Seems to work.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

---------------------------

From: [e-mail] (Tom Tulinsky)
Subject: how good is MacApp?
Date: Tue, 12 May 92 01:11:12 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

We are trying to decide whether to use MacApp or Open Interface, a platform
independent GUI that runs on Mac, Windows, and XWindows.  Portability is one
of our goals but if MacApp would make the application a lot faster to
develop, we could go with it.

Application: Electronic publishing; positioning ads in a magazine.  Requires:
- - pulldown menus, dialog boxes, text edit and pushbuttons
- - scrolling lists
- - dragging of objects (ads) by mouse
- - drawing text and scanned images to depict magazine in a scrolled window

We are very small and have a short time schedule so ease of use is paramount.
We are new to the Mac but experienced in C++, Motif, and Unix.

What is Open Interface, you ask? Its from Neuron Data in Palo Alto.  It seems
like Motif, but with somewhat less functionality.  It has an interactive
screen layout editor.  Its graphics are primitive and have no support
for images. You can escape to write platform specific code if it can't
do something.

- - How much better is MacApp than, say, Motif ?
- - How much would it help to read and display scanned images ?
- - Are there other advantages to using it ?



+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 12 May 92 15:10:43 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Tom Tulinsky) writes:
> We are trying to decide whether to use MacApp or Open Interface, a platform
> independent GUI that runs on Mac, Windows, and XWindows.  Portability is one
> of our goals but if MacApp would make the application a lot faster to
> develop, we could go with it.

At the Apple World Wide Developer's Conference this week Apple has
been hinting heavily that MacApp will go multiplatform.  They really
won't say, but they've repeatedly said to watch for a big announcement
at the upcoming PC Expo.

- --  Michael Peirce         --   [e-mail]
- --  Peirce Software        --   Suite 301, 719 Hibiscus Place
- --  Macintosh Programming  --   San Jose, California USA 95117
- --           & Consulting  --   voice: [phone] fax: [phone]
- --                         --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (Eric Berdahl)
Date: 12 May 92 18:44:00 GMT
Organization: Taligent, Inc.

Tom,

Preface all this with "I don't program Motif, and I don't know much about Open
Interface, but..."

MacApp is much more than a GUI.  In fact, MacApp doesn't really provide a GUI at
all, it just organizes the standard Macintosh UI elements into an
object-oriented framework.  MacApp has a number of tools that allow easy
composition of a UI layout.

But MacApp is much more than that.  MacApp is a class library for the
construction of Macintosh programs (if cross-platform compatibility is really
important, MacApp is _not_ your solution).  It provides a framework for doing
object-oriented appication development, with support for many of the various
areas common to Mac applications: a hierarchical view system, event handling, a
document metaphor, excellent memory management (truly, one of the biggest wins
of MacApp), elegant exception handling (neck and neck with memory management for
importance), and more.  Like any solution, it has its warts, but it truly is a
great way to develop applications (or quickly prototype) on a Mac.

For the things you listed, there is explicit support for the UI elements you
listed.  Dragging objects via mouse tracking is supported by a framework to do
mouse tracking.  To do it right, you would need to do some coding to handle the
specifics of your dragging, but the framework makes this relatively easy.
Drawing scanned images is a specific TView subclass that you would have to write
or get from someone (may I suggest the TGWorldView class from FotoApp, available
on E.T.O. #5).

As for reading scanned images, MacApp does provide a framework for reading files
whereby you only write the code to actually pull the bytes out of the file and
put them into your data structures.  This allows you to completely forget the
Mac File Manager and all its weird requirements.

Hope this helps.

- --
Eric Berdahl                                 MADA President
Internet: [e-mail]          AppleLink: BERDAHL
#include <StdDisclaimer.h>
This is a freeware signature.  What do you expect for nothing?

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 15 May 92 02:33:57 GMT
Organization: Reed College, Portland OR


  [e-mail] (Eric Berdahl) writes:
: MacApp is a class library for the construction of Macintosh programs....
: It provides a framework for doing object-oriented appication development,
: with support for many of the various areas common to Mac applications: a
: hierarchical view system, event handling, a document metaphor, excellent
: memory management (truly, one of the biggest wins of MacApp), elegant
: exception handling (neck and neck with memory management for importance),
: and more.  Like any solution, it has its warts, but it truly is a great
: way to develop applications (or quickly prototype) on a Mac.

  The warts mentioned above are quite understandable, ultimately. Aside
  from the significant delays I have come to expect from using MacApp
  applications in the real world, I am awestruck by the sophistication of
  the environments provided by them. PhotoShop and StrataVision are some
  of the most impressive applications I have ever seen, no matter how
  long they take to start up. The nuts and bolts of the memory management
  and exception handling reveal some radical devotion to doing things the
  right way, if not with an overt emphasis on speed.

  Still, I would prefer applications that come up without a very long
  delay, a stable memory space when the application is doing real work, a
  transparent means of using temporary memory for the bulk of open
  document and world memory usage, application heap sizes of 64k or so,
  an instantiated object browser within the application during testing,
  garbage collection and heap defragmentation that takes place
  incrementally at idle time, memory leak detection and identification,
  and an exception handling unit with a setjmp and longjmp that would get
  along with the debugging environment in Think Pascal.

  Everybody has their dreams, which we must pursue for ourselves...

  Theus ([e-mail])

---------------------------

From: [e-mail] (JohnC)
Subject: Off-screen Port Help & Interface Guidelines Question...
Date: 14 May 92 00:51:39 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (James Gustave) writes:
>
>I have two questions, the first is an aesthetic question about the interface,
>the second is a technical question about using offscreen ports.
>
>First, I'm writing a program that displays incoming serial data from a
>PowerGlove.  I'd like to have multiple windows open, each showing the
>data in a different format.  It looks odd to have a window in the
>background being drawn to, does that follow the interface standards?
>Is there a better way to do it?

There's nothing wrong with drawing into a window while your application is
not in front.

>Second, (and more importantly), I'm drawing the data first to an offscreen
>port then copying the bits to the windows, to reduce flicker.  This works fine,
>but it will overwrite anything that may be in front of the window, such as
>another window or even a screen saver.  Is there some way to test to see how
>much of the window is visible and only copy the bits into that area?  Is there
>another solution?

You must make absolutely sure that the grafPort (window) to which the
destination bitmap is attached is the current grafport (using _SetPort).  If
this is true, then _CopyBits will honor the grafPort's visRgn and clipRgn,
and thus not smash screen areas that are off-limits.  The documentation for
_CopyBits in IM-I mentions this fact.  If, for some unlikely reason, you
can't have the window be the current port, you can always tell _CopyBits the
legal drawing area manually via the maskRgn parameter.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (James Gustave)
Date: 14 May 92 03:36:30 GMT
Organization: University of California, Santa Cruz


Thanks!  The two replies I got were sufficient to solve my problem.
The program now works beautifully (at least I think so :)

- --
Jim Speth
[e-mail]

---------------------------

From: [e-mail] (Bradley Lamont)
Subject: 3d graphics programming
Date: 11 May 92 03:14:47 GMT
Organization: University of Illinois at Urbana

What abilities does the Mac have as far as 3d graphics are concerned?  I am
interested in porting a program I wrote on a SGI machine to the mac.

I need a way to set RGB colors, draw solid polygons, and map a 3d space
onto a 2d screen (i.e. viewing transformation).

I noticed in Think C that the libraries have a file called Graf3D which
has something called a GrafPort3D.  But I can't seem to find anything about
this in Inside Mac (vol 1-6).  Does apple not really support 3d color
graphics?

Please respond via email since I don't read this group regularly.

Thanks,
Brad

- --
/----------------------------------------------------------------------------\
|          Bradley H. Lamont          |  The University of Illinois          |
|       [e-mail]       |                at Urbana/Champaign   |
\----------------------------------------------------------------------------/

+++++++++++++++++++++++++++

From: [e-mail] (Reid Ellis)
Organization: Alias Research, Inc., Toronto ON Canada
Date: Tue, 12 May 1992 01:17:48 GMT

[Warning: I work for Alias, and helped write Alias Sketch!, so I may
 be a bit less than purely objective when it comes to the relative
 importance of 3D in the marketplace.. :-)]

Bradley Lamont <[e-mail]> writes:
|What abilities does the Mac have as far as 3d graphics are concerned?  I am
|interested in porting a program I wrote on a SGI machine to the mac.

You won't see anything approaching the GL library on the Mac.  The
closest thing is what you've already found, Graf3D, which is pretty
much a joke nowadays.

I think there are some third-party libraries out there.  Maybe someone
can comment?

|Does apple not really support 3d color
|graphics?

Got it in one.  What with the increasing prevalance of 3D software and
the need for 3D geometry to be handled as easily as 2D [PICT], I think
that Apple would be missing a rich market opportunity if they didn't
address this.

Reid
- --
Reid Ellis
[e-mail]        ||           [e-mail]
[e-mail] ||  [phone] [work]

+++++++++++++++++++++++++++

From: [e-mail] (Homayoon Akhiani)
Date: 12 May 92 22:21:08 GMT
Organization: Digital Equipment Corporation


 The following is a best port I ever saw of SGI GL.  They have drivers for
 almost everything, except MAC. The speed of the drivers are also very impressive
 I have look at their source code, it looks easy to write a driver for MAC.
 I am new to MAC world, hopefully someone with great exprience will low level
 QuickDraw should be able to port the driver else I will eventually do it.


======================

Article: 19441
From: [e-mail] (Eric H. Echidna)
Newsgroups: comp.graphics
Subject: VOGL - yet another SGI GL like graphics library.
Date: 14 Jun 91 07:37:49 GMT
Sender: [e-mail]
Organization: Comp Sci, University of Melbourne, Australia

Recently it came to our attention that someone might have
attempted developing an SGI GL compatible library using an early
version of VOGLE, and while not only giving very little credit to the
large amount of VOGLE code contained in it, even suggesting that VOGLE
was derivative work.

While we hope that any rumor concerning people grossly misrepresenting
work which was done by us will prove to be untrue (and this will be looked
into), it did seem like an interesting idea to find out how difficult it
would be to convert VOGLE to an SGI GL compatible library. As it turned out it
took about 60 marsupial hours spread over a period of four weeks to do it.

Although there are several SGI GL compatible libraries already
available, we believe this to be the only one that provides some
support for things like double buffering and backfacing, as well as
running on a variety of PC's in addition to X11, sunview, etc...
Consequently we have decided to make the result of our efforts (now
called VOGL) available and we would like to offer it as an example
of what can be done when the people who did the original work on one
problem address another problem of a similar nature, using the original
work, and their understanding of it, as the basis for finding a
solution. If there is sufficient interest, we will try to ensure
that bugs, enhancements, etc... are dealt with as they are sent to us.
The README is attached below.

We have also included a hershey library which is written in SGI GL, but
will also run with VOGL.

It is available via anonymous ftp from:

        gondwana.ecr.mu.oz.au:pub/vogl.tar.Z    [128.250.1.63]

- ---------------------cut here------------------cut here-----------------

The directories in this directory contain the source for the VOGL library
and the library hershey which is for manipulating the Hershey font data.

They are as follows:

    docs        contains the documentation such as there is.

    drivers        contains the source to a variety of device drivers,
            currently restricted to: postcript, sun workstation,
            apollo workstations, X11 (R2, R3 & R4), tektronix
            (401x), hpgl, dxy, and the ibm pc cards: hercules mono,
            cga, ega, vga and sigma.

    examples    contains some C and FORTRAN programs useful both in
            testing and (hopefully) learning how to use it.

    hershey        contains the source for the hershey library plus the
            source for generating fonts and the hershey data for
            the occidental and oriental character sets. Note: as
            with VOGL this library is callable in C and FORTRAN.

    src        contains the source for the C VOGL interface, and the
            source for the FORTRAN interfaces where available.

VOGL is a device portable graphics library that tries to be Silicon Graphics
Iris GL compatible. Our intention is that any VOGL program will compile
unchanged on a machine running SGI GL (the examples do). VOGL is based
entirely on our other graphics library VOGLE. While we still regard VOGLE
as our main library (it is, and probably will be for some time to come, the
one that gets the most use around here), we will gratefully accept any bug
fixes or enhancements. As always suggestions are also welcome.

This software may be used for any purpose commercial or otherwise. It is
offered without any guarantee as to its suitability for any purpose or as
to the sanity of its writers. We do ask that the source is passed on to
anyone that requests a copy, and that people who get copies don't go round
claiming they wrote it (that is why this one has a copyright notice in it,
see file COPYRIGHT).

Although VOGL is free we will drink any quantity of Beer you send to us.

Regards,

    Eric H. Echidna

Snail mail correspondance and alcoholic beverages should be directed to:

    The Software Support Programmer
    Department Of Engineering Computer Resources
    Faculty Of Engineering
    University Of Melbourne Vic 3052
    Australia

email to

    [e-mail]
    [e-mail]



- --
- -------------------------------------------------------------------------------
Homayoon Akhiani                               "Turning Ideas into ... Reality"
Digital Equipment Corporation                        "Alpha, The New Beginning"
77 Reed Rd. Hudson, MA 01701            "All Rights Reserved. Copyright(c)1992"
Email: [e-mail]     "The words are mine, and not my employer"
- -------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Organization: University of Illinois at Urbana
Date: Wed, 13 May 1992 01:02:00 GMT

We've got some sort of port of VOGLE done, and our stuff is generally free
(with source code). I say "sort of" because it doesn't do z-buffering, and
that makes it pretty limited right now (can you say "those polygons are being
drawn out of order"?) It's not blazingly fast, either. It's mostly complete,
though. [e-mail] (Dan LaLiberte) is the one handling it.
- --
Mark Lanett, NCSA Software Development - [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Christian Steffen Ove Franz)
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH)
Date: Wed, 13 May 1992 12:21:54 GMT

In article <[e-mail]> [e-mail] (Reid Ellis) writes:
>Bradley Lamont <[e-mail]> writes:
>|What abilities does the Mac have as far as 3d graphics are concerned?  I am
>|interested in porting a program I wrote on a SGI machine to the mac.
>
>You won't see anything approaching the GL library on the Mac.  The
>closest thing is what you've already found, Graf3D, which is pretty
>much a joke nowadays.
>
>I think there are some third-party libraries out there.  Maybe someone
>can comment?
>

Well, if all you need is some simple 3D grafsys that focuses on viewing trans-
formation and leaves the rest to the programmer, you can use the 3D graphics
library I wrote and submitted to sumex-aim a few weeks ago.
It is called 3D GrafSys 1.1 for programmers (the people at sumex-aim changed
that into 3d-graphics-library I think) and can be found in the
info-mac/source directory.

Maybe you should check it out to see if it does what you need to do. Compared to PHIGS it is much less sophisticated but still gets the most things done and
has a distinct advantage: it's free.

Cheers,
Christian.



- --
- -----------------------------------------------------------------------------
Christian S. O. Franz                 |                   [e-mail]
ETH Zuerich, Swizerland               |                     [e-mail]

---------------------------

From: [e-mail] (Per Bergland)
Subject: Trouble with resumeCmd (Sound Manager)
Date: 28 Apr 92 05:20:41 GMT
Organization: Chalmers University of Technology

Very strange! I allocate a sound channel, install a sampled sound as
an instrument, start a song consisting of freqDurationCmds and waitCmds,
 and then send a pauseCmd with SndDoImmediate.
When I a few seconds later send a resumeCmd, the machine crashes in _PrimeTime+
something at a jmp (A0) instruction where A0 contains some weird address like
ADB7BD7F.

So what's strange about that, you ask?

This only happens when running sys 6!!
Even 6.0.7, which supposedly has the same sound manager as sys 7, doesn't
help.
(Side issue : SndChannelStatus never shows status.scChannelPaused under ANY
system, even for a paused channel)

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 11 May 92 22:39:44 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Per Bergland) writes:
>
> Very strange! I allocate a sound channel, install a sampled sound as
> an instrument, start a song consisting of freqDurationCmds and waitCmds,
>  and then send a pauseCmd with SndDoImmediate.
> When I a few seconds later send a resumeCmd, the machine crashes in _PrimeTime+
> something at a jmp (A0) instruction where A0 contains some weird address like
> ADB7BD7F.
>
> So what's strange about that, you ask?
>
> This only happens when running sys 6!!
> Even 6.0.7, which supposedly has the same sound manager as sys 7, doesn't
> help.
> (Side issue : SndChannelStatus never shows status.scChannelPaused under ANY
> system, even for a paused channel)

It's probably a bug.  You should set the rate to 0.0 if you want to pause
a sampled sound.  Use getRateCmd to get the current rate, save it, and then
set the rate to 0.  Later call rateCmd again but this time with the old
rate.


- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 11 May 92 22:40:26 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Per Bergland) writes:
>
> Very strange! I allocate a sound channel, install a sampled sound as
> an instrument, start a song consisting of freqDurationCmds and waitCmds,
>  and then send a pauseCmd with SndDoImmediate.
> When I a few seconds later send a resumeCmd, the machine crashes in _PrimeTime+
> something at a jmp (A0) instruction where A0 contains some weird address like
> ADB7BD7F.
>
> So what's strange about that, you ask?
>
> This only happens when running sys 6!!
> Even 6.0.7, which supposedly has the same sound manager as sys 7, doesn't
> help.
> (Side issue : SndChannelStatus never shows status.scChannelPaused under ANY
> system, even for a paused channel)

It's probably a bug.  You should set the rate to 0.0 if you want to pause
a sampled sound.  Use getRateCmd to get the current rate, save it, and then
set the rate to 0.  Later call rateCmd again but this time with the old
rate.


- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

---------------------------

From: [e-mail]
Subject: preloaded and purgable resources (Q)
Date: 29 Apr 92 22:19:23 GMT
Organization: BC Systems Corporation

I don't know if this is an FAQ (I don't think it is) but I was wandering
how much I would benefit from PreLoaded resources.

For example: I have some PICT resources and some CURS resources that I usually
have set to "pugeable" for memory reasons.  This was recomended by
someone/where I read.  anyway, in a program where you access these resources
through resource ID's, do the routines access the resource fork anyway, thus
bypassing the fact that they _may_ be 'preloaded' or do they check if they are
in memory first?

Also, if you have 'preload'd resources, shoud you also have the purgeable flag
set or is this stupid??

I hope I'm clear enough on this.  Any help is muchly appreciated!!

- --
[e-mail]
    or
[e-mail]
Victoria, British Columbia, Canada

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 29 Apr 92 23:48:51 GMT
Organization: Kalamazoo College

[e-mail] writes:
> I was wandering
>how much I would benefit from PreLoaded resources.
>
>For example: I have some PICT resources and some CURS resources that I usually
>have set to "pugeable" for memory reasons.  This was recomended by
>someone/where I read.  anyway, in a program where you access these resources
>through resource ID's, do the routines access the resource fork anyway, thus
>bypassing the fact that they _may_ be 'preloaded' or do they check if they are
>in memory first?
>
>Also, if you have 'preload'd resources, shoud you also have the purgeable flag
>set or is this stupid??

The 'preload' flag is a quick'n'easy way of getting those resources into
memory without calling GetResource().  Additionally, it guarantees that
they will loaded extremely low in the heap.

Because of this second feature, it's not a real good idea to get rid of
preloaded resources.  It's inefficient to have free memory mingled with
a bunch of pointers and locked handles, which is usually what occupies
the lower heap locations.  So no, you probably don't want them purgeable
as well;  you may want to lock them, in fact.

To answer your first question:  the Resource Mananger will always do the
Right Thing--it will use a memory-resident copy if it can, and load a
copy from disk if it must.  Preloading doesn't affect this.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Ceci n'est pas une .signature.

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 13 May 92 17:09:25 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] writes:
>
> I don't know if this is an FAQ (I don't think it is) but I was wandering
> how much I would benefit from PreLoaded resources.
>
> For example: I have some PICT resources and some CURS resources that I usually
> have set to "pugeable" for memory reasons.  This was recomended by
> someone/where I read.  anyway, in a program where you access these resources
> through resource ID's, do the routines access the resource fork anyway, thus
> bypassing the fact that they _may_ be 'preloaded' or do they check if they are
> in memory first?
>
> Also, if you have 'preload'd resources, shoud you also have the purgeable flag
> set or is this stupid??
>
> I hope I'm clear enough on this.  Any help is muchly appreciated!!
>

  I believe the original intent of preloaded resources was to get them in
memory right away, so that the user would not suffer from a disk access
(remember, we're talking about 400K floppies here) during his session.
Preloaded resources are loaded very soon after the application heap is
created, so the rest of the program probably hasn't loaded yet.  Put the disk
access with the rest of the disk access.
  These days, with 5000 meg, 3 nanosecond access time hard drives, preloaded
resources don't make a lot of sense in this regard.  However, this mechanism
is still really useful to help with heap fragmentation.  If you also set the
locked bit on preloaded resources, they get loaded as low in the heap as
possible.  If you have resources that tend to stay in memory for the entire
time your application is running, you might want to think about this to help
manage your memory.
  You should set the purgeable bit on resources that aren't used that frequently,
so it doesn't matter if they go away when you're running low on memory.  For
example, in System Software, all the 'PACK' resources are purgeable, since they're
only used every once in a while, and it's pointless to have them using system heap
memory when that memory can be used for something else.  If you keep the handle to
purgeable resources cached, though, remember to call LoadResource to make sure the
resource is in memory before you start using it.
  So the long and short of it is, having a preloaded, purgeable resource doesn't
make a whole lot of sense these days, but then again, you might have a really good
reason to want to do this that I can't see with my rainbow colored tunnel vision.

  -- Dean Yu
     Blue Meanie, Negative Ethnic Role Model, Window Cleaner,
      Skanky Hack Consultant, etc.
     Apple Computer, Inc.
     Wondering why I'm in the office when I could be at the WWDC...

---------------------------

From: [e-mail] (Steve Herman)
Subject: 'STR ' resource question
Organization: Boeing Computer Support Services (BCSS)
Date: Thu, 14 May 1992 15:37:48 GMT

    Excuse me in advance if this is a FAQ but...

    Just out of curiosity, what is the DATA field of an 'STR ' resource type
used for.  Is it just for whatever suits your fancy?  If so, what are some
examples of it's use?

Thanks,
Steve


- -------------------------------------
Steve Herman - BCSS
"Happiness is just a 'Flaming Moe' away"
    - Moe the Bartender
- -------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 15 May 92 01:32:56 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Steve Herman) writes:
>
>     Just out of curiosity, what is the DATA field of an 'STR ' resource type
> used for.  Is it just for whatever suits your fancy?  If so, what are some
> examples of it's use?

I guess you are seeing this DATA field in ResEdit? I believe that the DATA field
is there simply to show any data that comes after the string. In a perfect
world, a 'STR ' resource simply holds a length byte followed by that many
characters. However, if ResEdit finds extra bytes after the string, it will show
them in the DATA field. They shouldn't be there, but ResEdit shows them to you
to indicate that something might be wrong.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail]
Subject: How to swab two bytes?
Date: 14 May 92 23:42:39 GMT


Hi!

   I have a problem about swabing two bytes in the memory.  Can someone tell
me how to do it?  The reason why I need this to be done is because the MS-DOs
computers store the integer least significant byte first.  So I need to
convert it to the Mac integer format which is the reverse of LSB.

   Please don't flame me if this is a stupid question.  Thank you very much
in advance for any help.

Nick Yang   [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Charlie Reiman)
Organization: University of Illinois at Urbana
Date: Fri, 15 May 1992 18:02:50 GMT

[e-mail] writes:


>Hi!

>   I have a problem about swabing two bytes in the memory.  Can someone tell
>me how to do it?  The reason why I need this to be done is because the MS-DOs
>computers store the integer least significant byte first.  So I need to
>convert it to the Mac integer format which is the reverse of LSB.

>   Please don't flame me if this is a stupid question.  Thank you very much
>in advance for any help.

Okay, I'll just ridicule you a little bit.

1) Get some tweezers. Bytes are very small; you'll need something to hold
onto them with while your swabbing them.

2) Buy some good byte polish. I recommend Uncle Al's Mink Oil Flux Soap.
It has a nice, fruity smell.

3) Remove the bytes, and apply the sopa, using a clean, static free,
lint free cloth.  Use a circular motion.

4) Let the polish dry to a white film, then wipe clean with a second cloth.

5) Replace the bytes, and away you go!

Or, if you are out of soap, you could swap the bytes. This is faster,
but less fun.

long swap(long in) {
    long out;
    char *inp,*outp;

    inp=(char *)∈
    outp=(char *)&outp;

    outp[0]=inp[3];
    outp[1]=inp[2];
    outp[2]=inp[1];
    outp[3]=inp[0];

    return out;
    }

There are many variants on this theme. Ideally, you would have htonl,
htons, et al. lying around and you wouldn't have to do all this
nonsense by hand.

- --
Charlie Reiman - [e-mail]
Have a bajillion brilliant Jobsian lithium licks.

---------------------------

End of C.S.M.P. Digest
**********************